Number-crunching computer software (“computer software” is hereinafter referred to simply as “software”) that handles spreadsheets having a tabular data structure with rows and columns, such as “Excel” (trademark of Microsoft Corp.), is often used in personal computers (hereinafter referred to simply as “PC”).
The objectives of the user to use the spreadsheet software include using the data entered in the spreadsheets as a report and using the spreadsheets as a simplified version of the tables of the database (hereinafter referred to simply as “DB”), in addition to number-crunching. Especially, the spreadsheets, which are similar in data structure to DB tables, are suitable for management of relatively small-sized data. Thus, the spreadsheet software is used more frequently than DB software.
As means to obtain results similar to DB tables by use of the spreadsheet software, sort and filter functions are available. The sort function is to specify a column of a spreadsheet to rearrange data of that column in ascending or descending order, thereby facilitating a search for desired data. The filter function is to specify a column of a spreadsheet to select or delete only specific values of data in that column. By using such functions, a specific group of data in the spreadsheet may be selected or emphasized. Because these functions are similar to specifying the arranging order of output data for the DB table or setting the search criteria, simple selection processing may be readily executed by the spreadsheet software and thus is routinely performed.
In this way, the spreadsheet software may be used in place of the DB software, but it suffers the following problems:
(1) Problem in Unitary Management
As it becomes popular to substitute spreadsheets for DB tables, it is sometimes difficult to manage data when they are scattered all over in multiples.
For example, let us assume that after a list of people to which New Year's cards are to be sent in 2002 is created in a spreadsheet, an address list of New Year's cards for the next year (2003) is created based on that spreadsheet. In one case for creating the address list, the original list is updated/registered as is. In another case, the 2002's list is saved before copying the 2002's list and updating/registering it for the 2003's. In the latter case, if similar lists, such as those for address change notifications, midyear gifts, summer greeting cards, acquaintances' addresses, alumni, and cellphone numbers, as well as New Year's cards, are created based on a single spreadsheet, and they are accumulated, then a problem will occur in their management.
In that case, for personal data, the amount of its data is typically small, so that it is relatively easy to determine which is original data and which is the latest data; however, if such practice is performed in a disorderly fashion by a company having greater numbers of customers, it is quite likely that they become difficult to fathom. To avoid such a situation, unitary management of data in some form is required.
In order to perform unitary management, however, it is necessary to gain knowledge about the DB and learn how to use it, as well as creating an environment where the DB is readily accessible. This imposes a greater burden on the user who wants to implement data management through friendly operations of the spreadsheet software.
(2) Difficulty in Table Merge
With the existing spreadsheet software, it is relatively easy to split a single spreadsheet (table split), extract a portion of data, and perform other simple processing; on the other hand, for merging of multiple spreadsheets (table merge), it cannot be done collectively unless positions of “columns” and arranging orders of “rows” are commonly determined. If the layout of the spreadsheet is determined, a macro function for pre-describing the merge procedure may be used to execute it automatically, although, to write a macro, it is necessary to acquire knowledge about the macro function and program it. However, the number of persons who have learned the macros and are capable of programming them is very limited. In addition, macro programming presumes that the same procedure is repeated; thus, it is not practical to program a macro merely for an operation of makeshift nature.
There is an approach to converting a spreadsheet into a single table of a database before registering it, and defining a relationship between tables registered in the DB, so that multiple tables logically appear as if they were a single table. In that case, too, it is necessary to obtain knowledge about the DB and learn how to use it, as well as creating an environment where the DB is readily accessible, which raises a problem in that a greater burden is imposed on the user.
(3) Difficulty in Data Selection for Composite Criteria
Data selection from a sorted or filtered spreadsheet suffers a significant limitation, as compared to processing on DB tables.
For example, consider a spreadsheet that contains sales records of chain stores. This spreadsheet is assumed to contain data on chain store names, sales amounts, target sales amounts, achievement ratios, expenditures, gross margins, final profits, sales counts of focus product A, and sales counts of focus product B. Based on such a spreadsheet, it is easy to create a list in order of sales amounts, a list in order of achievement ratios, and a list in order of gross margins.
However, as the criteria become more complex, as in a case where chain stores that meet three criteria, i.e., sales amounts of 1 million yen or less, sales target achievement ratios of 60% or less, and gross margins of 0.3 million yen or less, are selected, it is increasingly difficult to do so.
For example, if chain stores that meet all of the three criteria are determined by an “∩” (AND) condition, a list of chain stores that only meet the criterion of sales amounts is first created via the sort and filter functions; the chain stores that meet the criterion of sales target achievement ratios are then narrowed down from the list created; and, finally, the resulting chain stores are further narrowed down by the criterion of gross margins, thereby determining chain stores that meet all of the three criteria.
If chain stores that meet either of the three criteria are determined by an “∪” (OR) condition, lists of stores that meet the respective criteria are first created; however, with such lists, there may be cases where same chain stores overlap; thus, creating lists with such overlaps removed would involve cumbersome procedures.
Furthermore, if three criteria are more complex than simple “∩” or “∪”, for example, if you want to determine the most problematic chain store where multiple criteria overlap, and then the next problematic chain store, the resulting difficulty becomes more apparent.
The objective of the present invention is to solve the afore-described problems and to provide a data management system and data management method that enables spreadsheet management through a simple operation.
Another objective of the present invention is to provide a recording medium that allows the computer to execute said data management method.